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The nslookup program is very useful in 
finding the IP address of any host on 
the Internet. It's also very useful in de- 
bugging Domain Name System (DNS) prob- 
lems. Sometimes, troubleshooting can be 
done by running nslookup as a name server 
for doing lookups. Doing this manually on 
nslookup can be tedious and time-consuming. 
This article offers a tool that makes this kind 
of DNS troubleshooting very convenient. 

A quick DNS lookup overview 

The DNS system is based on the client and 
server model shown in Figure A. The client 
that needs to look up a domain name (for 
example, www.zdjournals.com) is called the 
resolver, and the server that's resolving the 



dbg_dns.pl 



internet 




nslookup 



local name 
server 



Figure A: The DNS communication flow is 
shown here. 



domain, called the Name Server (NS), goes 
to the Internet to find the IP address of the 
domain. A resolver sends specific queries 
to the NS, passing the domain name as the 
argument. 

There are two kinds of queries: recursive 
and non-recursive (or iterative). In both cases, 
the name server first checks to see if it has the 
information in its cache; then it returns that 
result. In a recursive query, the resolver sends 
the query with a domain name, and the NS 
goes out to the Internet and talks to other 
name servers on behalf of the resolver, even- 
tually returning the IP address to the resolver. 
In a non-recursive query, the name server 
doesn't do all of the work; rather, it returns a 
list of name servers (known as referrals) that 
it thinks can provide the answer. The resolver 
then sends a similar non-recursive query to 
each name server in that list until it gets the 
answer. 

Normally, when you run nslookup, it runs 
as a resolver and sends a recursive query to 
the local name server. The local name server, 
in turn, temporarily acts as a resolver and 
sends non-recursive queries to the other name 
servers in the DNS tree, so that it contacts each 
referral in a depth-first fashion until it finds a 
name server that returns the IP address. 

An example of domain lookup using 
nslookup is shown here. Our keystrokes 
are in color. The <host.company.com> will 
be the actual local name server (the > is the 
nslookup prompt): 
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$ ns Lookup 

Default Server: host.company.com 
Address: 128.69.113.172 

> www.zdjournals.com 
Server: host.company.com 
Address: 128.69.113.172 

Name: www.zdjournals.com 
Address: 152.175.1.108 

>exi t 

Here, nslookup as a resolver sends a recur- 
sive query (which is default), and the server 
system host.company.com resolves the query 
with a crisp answer containing the IP address. 
However, this session doesn't tell the whole 
story as to how the name server went about 
resolving the query. 

During troubleshooting, it's necessary to 
look under the hood and see what intermediate 
name servers are being used. In other words, 
we need to be able to see like a name server. 
This is where nslookup comes to the rescue. 
Nslookup can emulate either a resolver or a 
name server. We saw how it emulated a re- 
solver above. To emulate a name server, it can 
be invoked with these options: 

$ nslookup -norecurse -nosearch 

The -norecurse tells nslookup to send non- 
recursive queries to the local name server. The 
-nosearch options tells it to not use the search- 
list because name servers don't. When you 



enter a domain in this mode, the default name 
server returns a list of name servers. We then 
tell nslookup to use one of those name servers 
as the default server and look up the domain 
again. Repeating this process eventually re- 
turns the IP address. 

Tool design 

We need to do this kind of troubleshooting re- 
peatedly, but for many domains it will be very 
inefficient and difficult. Our tool automates 
this activity in a Perl script. The idea is to in- 
voke nslookup in a child process and set up 
a communication channel between our Perl 
script and nslookup. Thus, instead of us doing 
all the tedious work, the parent process takes 
the domain name and talks to the nslookup 
process and finally shows the path it traversed 
along the DNS tree, showing each name server 
it had to contact. Listing A shows the Perl script 
that implements this, and Figure A shows how 
the communication process is set up. 

The tool has several options. You can per- 
form inverse lookups (that is, enter an IP ad- 
dress and get the domain name). Also, you can 
provide it a list file of domains for a batch job. 
Listing B on page 5 shows sample runs of the 
tool. The dbg_dns.pl is the name of the tool. 
Use a higher verbose level to see more output. 

Conclusion 

This tool provides a means to perform a tedious 
task conveniently and allows you to debug 
problems by showing the DNS tree path being 
taken to resolve a domain name. 



Listing A: Require "getopts.pl"; 



# This script shows the path of DNS tree followed to 

# obtain the ip address of a domain. 
# 

Sdom=$ARGV[S#ARGV]; 

$cnt=0; #starts at 0 upto Sent . so total NSs = $cnt+1 
»IP=""; 

$def server=""; 

# Expected patterns tor matching; Change if needed. 
$NED="Non-exi stent domain"; 

$NRFS="No response from server"; 
$SB=" A Served by:"; 

$AAFF=""Authoritative answers can be found from:"; 

$NS="nameserver = "; 

$N1=""Name:"; 

$Addr=" A Address: "; 

$Addrs="~Addresses:"; 

$N2="name = "; 

$NA="(non-authori tative)"; 

$DS="*Default Server: "; 



$usage="usage: $0 [options] [domain] 
<options> : 

-v<level> : verbose level 1-5 

-i : inverse guery 

-f : force (use domain as given) 

-l<file> : path of the listfile, one per tine 
<domain> : domain e.g. www.whitehouse.gov \n\n"; 

sub getOpts 
( 

(! 8Getopts('v:l:ifh')) U die Susage; 
(topt_l) 88 ($in_file=$opt_l) 88 return; 
( Sop t_h ) 88, die "\n$usage"; 
8chkValidDom; 



sub chkValidDom 
{ 

(topt_i) 88 (!$opt_f) 88 
(($dom =" /[A-Z]/) !! ($dom =' /[a-z]/)) 
die "\ninvalid IP address: $dom\n"; 
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Listing A: Continued 



(!$opt_i) S& ( !$opt_f ) U ( Sdom =" /[0-9]/) 
die "\ninvalid domain name: $dom\n"; 



sub debug 
{ 



.[0] <= $opt_v) U print STDOUT •_[!]; 



sub cleanup 
{ 



Scnt=0; Stot=0; Sdom=""; 
SIP=""; SnonAuth=""; 



sub lookup 
( 

local(Sserver) = ®_[0]; 

I oca L ( $ type ) =®_[1]; #' fwd '=f orward; ' i nv'=inverse 
SstillNS=0; #s till NS= 1 means referrals returned 

$buf=""; #saves the answer from nslookup 

&debug(4, "parent: setting server to 'Sserver' \n"); 
&debug(4. "parent: writing 'Sdom'\n"); 

#set the server 

print Pwfd "server Sserver\n"; 

# read back the output from nslookup 

Sbyte="0"; while (Sbyte ne ">"){ read(Prtd, Sbyte. 1);} 

# clear out but; enter domain and read output 
print Pwfd "Sdom\n"; 

Sbyte="0"; 

whi le (Sbyte ne ">" ){ 
read(Prfd, Sbyte, 1); 
Sdebug ( 5 . "parent: read char: Sbyte\n"); 
Sbuf .= Sbyte; 

) 

&debug(4, output read back: — \nSbuf\n"); 
8debug(4. "— output read back end: — \n\n"); 

#write the output to a file for file processing. 
open(th, "> /tmp/nslk.out"); 
print th Sbuf; 
close! th); 

# if NS fails to find domain, return error 
open(th, "< /tmp/nslk.out"); 
while(<th>){ 

if((/SNED/i)!!(/SNRFS/i)){ 
close) th); 
print STDOUT S_; 
return 1; 
} 

} 

close(th); 

# if NSs returned, read them into an array, 
if (Stype =" /fwd/ ){ 

Si =0; SretNSlisUOU""; 
open(th, "< /tmp/nslk.out"); 
while(<th>){ 
if (/SSB/M 

SstillNS=1; 



1 

if ((/"- /) U (SstillNS » 1)) | 
chop; 

®a=split(/ /, $_); 

$retNSlist[$i ++ ]=Sa[1); 

} 

} 

close! th); 

} 

e I se{ 

Si=0; SretNSlist[0]=""; 
open(th, "< /tmp/nslk.out"); 
while(<th>){ 
if (/SAAFF/H 

SstillNS=1; 

} 

if ((/SNS/) U (SstillNS == 1)) { 
chop; 

®a=split(/ = /. SJ; 
SretNSlist[Sif]=Sa[1]; 

( 

) 

close(th); 

} 

# Try each next NS if one fails 
if (SstillNSM 

for (Sj=0; Sj < Si; $j++) 

I 

Snslist[++Scnt] = SretNSlist[$j ]; 
&debug(1. "trying SretNSlisttSj ]\n"); 
if (Stype =" /fwd/)( 
if (! 8lookup(SretNSlist[Sj], "fwd"))f 
last; 
1 

1 

else{ 

if (! &lookup(SretNSlist[$j], "inv")){ 
last; 
1 

) 
1 

) 

else{ # Get the IP addr. of the hostname 

open(th, "< /tmp/nslk.out"); 

if (Stype =" /fwd/){ 
whi le(<th>){ 

if (/SN1/){ 
Sfound=1; 

) 

if ( ((/SAddr/) II (/SAddrs/)) U 
(Sfound == 1))( 
chop; 

•a=split(/:/. S_); 
SIP=Sa[1]; 
last; 
} 

t 

1 

else{ 
vhile(<th>)( 

if (/SN2/){ 

chop; 

»a=split(/ = /, S_); 

$IP=Sa[1l; 
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Listing A: Continued 



Last; 

} 

( 

} 

close( th); 

1 

return 0; 
( 

sub do_process 
{ 

Loca L ( $ tdom ) = 

Sdom = Stdom; 
8chkValidDom; 

# set first NS in the list to local NS 
$nslist[$cnt]=$defserver; #don't increment Sent here 

if ( Sop t_i == 1 ){ #inverse lookup requested 
8lookup($def server, "inv"); 
} else{ 

&lookup(Sdefserver, "fwd"); 
} 

# present results 

Stot = Sent + 1; #$cnt had started at 0 

print STDOUT "\nThe NSs( tot=$tot ) contacted for \ 

'Jdom' were:\n"; 

for ($j=0; $j <= Sent; $j++) { 
$t=sprintf('V40s\n". $nslist[$j ]); 
print STDOUT St; 

} 

(Sent == 0) 88 ($nonAuth="$NA"); 
if (Sopt_i){ 

print STDOUT "hostname of Sdom SnonAuth = $IP\n"; 
}else( 

print STDOUT "IP addr of $dom JnonAuth = $IP\n"; 

} 

8cleanup; 

} 

# ma in 

($#ARGV < O) 88 die "\n$usage"; 
8getOpts( ); 

# spawn a child to take ns lookup commands 
pipe(Crfd. Pwfd); #Child reads 8 Parent writes it 
pipe(Prfd. Cwfd); #Parent reads 8 Child writes it 
if (Schpid = fork ){ # parent here 

8debug(4, "I am parent\n" ); 

8debug(4, "child chpid = $chpid\n"); 

close(Cwfd); 

close(Crfd); 

select(Pwfd); $! = 1; 

# Get the Default server from nslookup startup 



$byte="0 "; 

whi le ($byte ne ">"){ 
read(Prfd, Jbyte, 1 ); 
$buf .= Sbyte; 

) 

open(hdl, "> /tmp/nslk. start"); 

print hdl Sbuf; 

close(hdl); 

openfhdl, "/tmp/nslk. start"); 
while(<hdl>) { 
if (/$DS/)( 

®a=split(/\s/. $_); 
chop; 

$def server=Ja[3]; 

$tstr= "default server=$a[3]\n"; 

8debug(3, Ststr); 

last; 

) 

) 

close(hdl ); 

if ($opt_i == 1){ 

print Pwfd "set type=ptr\n"; 

#read back the initial output from nslookup 

$byte="0";whi le (Sbyte ne ">") (read(Prfd, Sbyte. 1); ) 

) 

if (Sin_file)( 

open(listh, Sin_file) !! die "can't open input file\n"; 
while(<listh>){ 

/"#/ 88 next; 

(Ststr="\n Looking up ",) .= S_; 

8debug(1. Ststr); 
chop; 

8do_process($_); 

I 

close( listh); 
) 

elsef 
8do_process(Sdom); 
1 

close(Pwfd); 

) 

else { # chi Id here 

8debug(4, "I am chi ld\n"); 

# Child stdin, out, err all now from/to the pipes 

open(STDIN, "<8Crfd") II die "Can't dup child stdin"; 

open(STDOUT. ">8Cwfd") II 
die "Can' t dup chi Id stdout"; 

open(STDERR, ">8STDOUT") II 
die "Can't dup child stderr"; 

select (STDOUT); $1 = 1; 

close(Prfd); close(Pwfd); 

close(Crfd); close(Cwfd); 

exec("nslookup -norecurse -nosearch"); 



Coming up... 

• Solaris 7 security 

• Using hosts.allow and hosts.deny 
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Listing B: Sample runs with our Pearl nslookup script 



t perl dbg_dns.pl www.zdjournals.com 

The NSs( tot=3) contacted for 'www.zdjournals.com' wer 
hos t . company.com 
B. ROOT-SERVERS. NET 
NS1.T00L.NET 

IP addr of www.zdjournals.com = 152.175.1.108 
$ 



$ perl dbg_dns.pl www.ang.af.mil 

e: The NSs(tot=4) contacted for 'www.ang.af.mil' were: 
host.company.com 
CROOT-SERVERS.NET 
MARS.AF.mil 
NS.ANG.af.mil 

IPaddrofwww.ang.af.mil = 132.80.207.6 



Makelndex: a tapepiltty 




by Arthur Haigh 

I'm fond of my backup tapes. They have 
saved the day more than just once. The 
problem I have, however, is not in making 
the backup tapes, but in keeping track of what's 
on them and when they were made. I'm sure 
I'm not the only systems administrator that 
has a pile of mystery tapes lying around. To 
help me keep that pile manageable, I wrote 
the Makelndex script. 

What's an index? 

My backup scripts are similar to those pre- 
sented in "Practical backups for the small 
Solaris system," in the June 1998 issue, and 
"No-brainer backup," in the November 1998 
issue. The scripts create one ufsdump file 
per file system and sequentially put them 
onto tape. 

In this article, I'll present a short Bourne 
shell script, called Makelndex, that will take 
a tape that has been created with multiple 
ufsdump files and create an index of those 
files. The script doesn't create what the So- 
laris ufsrestore man page refers to as a table 
of contents. A table of contents is a list of every 
file and directory that's backed up within a 
ufsdump file. The Makelndex script creates 
a list, including the name of each file system 
mount point, the date the dump was created, 
and the level of the dump. 

The script is a hands-off program. One sim- 
ply inserts a tape and executes the script. The 
index is written to standard output. The tape 
is automatically rewound and ejected when 
finished. 



Creating the tape index 

Execution of the Makelndex script produces 
the output shown in Listing A. The script 
shows that the host europa had its root (/), 
/usr and /export /home filesystems dumped 
(with level 0 dump) on Thursday, February 
18 th at about 7:00 P.M. In addition, europa had 




new \ 

IMPS 



Listing A: Standard output from the execution of the 
Makelndex shell script 

# ./Makelndex 
File: 0 

Dump date: Thu Feb 18 19:07:03 1999 
Dumped from: the epoch 

Level 0 dump of / on europa:/dev/dsk/cOt3dOsO 
File: 1 

Dump date: Thu Feb 18 19:18:00 1999 
Dumped from: the epoch 

Level 0 dump of /usr on europa : /dev/dsk/c0t3d0s5 
File: 2 

Dump date: Thu Feb 18 19:31:23 1999 
Dumped from: the epoch 

Level 0 dump of /export/home on europa:/dev/dsk/cOt3dOs6 
File: 3 

Dump date: Thu Feb 18 19:51:53 1999 
Dumped from: Wed Feb 17 04:07:04 1999 
Level 2 dump of /var on europa:/dev/dsk/c0t3d0s7 

File: 4 
E0M 
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the /var file system dumped at a level 2 dump 
on Thursday, February 18 th . The line reading 

Dumped from: Wed Feb 17 04:07:04 1999 

indicates the date of the last lower level dump 
of /var. For a plethora of information on dump 
levels, refer to the man pages on uf sdump. You 
may have noticed that the file systems that 
had been dumped at level 0 produced the line: 

Dumped from: the epoch 

This indicates that there's no previous lower- 
level dump for this file system. 

Picking it apart 

The shell is shown in Listing B. Line 1 defines 
the shell as a Bourne shell. The variable TAPE 
is defined on line 7, and line 8 initializes the 
variable ERROR. 

Typically the backup consists of a series of 
dump files. The while loop will loop over the 
number of files. For the sake of simplicity per- 
formance, and flexibility the script doesn't de- 
termine the number of files to loop over before 
looping. Rather, the while loop continues as 
long as the value of the variable ERROR is zero. 
You can see in line 12 of Listing B that the file 
number of the first record is determined by 
pruning the file number from the output of the 



Listing B: The Makelndex shell script 



1 


#! /bin/sh 




2 


# 




3 


# 




4 


# Makelndex: Creates an index 


for a tape in ufsdump format 


5 


# 




6 


# 




7 


TAPE=/dev/rmt/0n 




8 


ERR0R=0 




9 






10 


while [ SERROR -eq 0 ] 




11 


do 




12 


FILENUM='mt -f STAPE status ! 


grep f i le 1 awk '{print $3 }' " 


13 


echo "\nFile: SFILENUM" 




14 


echo "qu i t \c" 1 u f sres t ore -ivf 


STAPE 2>/dev/nu 1 1 ! grep "ump" 


15 


# echo "quit\c"!ufsrestore -ivf 


STAPE 2>/dev/null!grep "ump " 


1G 


ERR0R=S? 




17 


done 




18 


echo "EOM" 




19 


mt STAPE rewoffl & 




20 


exi t 





mt status command. The standard output from 
the mt command is piped to grep file and then 
further reduced by piping to the awk command. 
The result, a number indicating the current file 
position on the tape is assigned to the variable 
FILENUM. Line 13 echoes the file number to stan- 
dard output. 

The heart of the shell 

Line 14 is the heart of the shell and, like line 
12, jams many commands into this one line. 
At the heart of this line is the command: 

ufsrestore -ivf STAPE 

You can see that the -ivf parameters are 
used. The - i v invokes the verbose and interac- 
tive modes. The f parameter indicates that we 
wish to read from the file represented by the 
variable TAPE. Remember, in UNIX, devices are 
files. We aren't really interested in using the 
interactive mode of ufsrestore, though. We 
use the interactive mode because, when it's in- 
voked, the command generates a description 
of the dump file, which includes the file system 
that was dumped, the date of the dump, and 
the dump level. Unfortunately, the command 
gives us more information than we need, in- 
cluding a prompt for interactive use. Here's 
what it gives us: 

# /usr/sbin/ufsrestore -ivf STAPE 

Verify volume and initialize maps 

Media block size is 126 

Dump date: Thur Feb 18 19:18:00 1999 

Dumped from: the epoch 

Level 0 dump of /usr on europa:/dev/ 

*»dsk/c0t3d0s5 

Label: none 

Extract directories from tape 
Initialize symbol table, 
uf srestore> 

The ufsrestore command directs the prompt 
to standard error, which is, by default, repre- 
sented by file number 2. You can see, in line 14 
of Listing B, that the standard error is redirect- 
ed to suppress the prompt: 

ufsrestore -ivf STAPE 2>/dev/null 

To rid our index of unwanted information 
produced from the ufsrestore command, we 
can redirect the standard output to the grep 
command to pick out only the information 
of interest. We're interested only in lines that 
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have the string dump in them. These include 
Dump, Dumped, and dump. We pipe the out- 
put to grep and search for these strings. We 
need to restrict our search string to pick out 
the string ump: 

ufsrestore -ivf $TAPE 2>/dev/ 
^null ! grep "ump" 

Since we invoked the interactive mode, we 
need to enter the qui t command to ufsrestore' s 
standard input. We can again use a pipe to re- 
direct the output of the echo to the input of 
ufsrestore: 

echo "qui 1 \c" ! ufsrestore -ivf $TAPE 2>/ 
*»dev/nul L i grep "ump" 

Finishing up the loop 

Immediately following the ufsrestore command 
is the assignment of the variable ERROR. Line 16 
assigns the return code from the previous com- 
mand issued using the built-in shell variable $?. 
If the ufsrestore command was successful, then 
a zero is returned and the whi le loop continues. 
If zero isn't returned, indicating an error, the 
wh i I e loop finishes. The error we foresee is 
when there are no more dump files to restore. 
When the ufsrestore command fails, we're fin- 
ished with the loop. 

In line 18, 1 have the script echo EOM (for End 
of Media) to indicate that there are no more 
dump files on this tape. The mt command is 
then issued to run in detached mode (line 19). 
The tape is rewound and then ejected by the 
rewof f I option, which means rewind and take 



offline. Since the mt command is detached, the 
shell is free to exit without waiting for the re- 
wind to finish. 

Since I almost always perform level 0 dumps, 
I got tired of seeing the line 

Dumped from: the epoch 

If you're not interested in the dump level, or if 
you just don't like seeing the facetious reference 
to the epoch, you can comment out line 14 in 
Listing B and uncomment line 15. The differ- 
ence between these lines is simply a space at the 
end of the string ump. The space eliminates the 
occurrence of the string containing Dumped in the 
Makelndex output. 

Conclusion 

The Makelndex script is simple, flexible, and 
versatile. Used as printed in Listing B, the 
script provides a hands-off utility for identify- 
ing and verifying the contents of your tapes. 
The commands can be incorporated at the end 
of a uf sdump backup script to verify the backup. 
You can be sure that the backup was successful 
because the Makelndex program is reading the 
tape. Finally, you can redirect the standard out- 
put of the Makelndex command to a file to cre- 
ate written records that can be filed or printed 
and attached to the tape. 

The uf sdump command is an excellent resource 
for creating backups. Coupled with this handy 
script, you'll be able to simplify and automate 
the creation, verification, and organization of 
your valuable tapes. 



Managing licenses 




by Vinay Gupta 

I know it's bad to talk about license man- 
agers when the software paradigm is 
moving towards freeware. But, in reality, 
we use many software products that are li- 
censed. Flexlm is one license manager that 
comes by default with the Solaris operating 
system and is the most widely used license 
manager among software developers. 

Management of licenses becomes more dif- 
ficult when application vendors assume that 



their application is the only application (with 
licenses) running on your machine. This some- 
times leads to a lot of confusion and may stop 
other license daemons from running on the 
machine. 

License file semantics 

A typical license file has three main cate- 
gories: server identifier, application license 
daemon identifier, and application feature 
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(or increments) identifier. Server identifier has 
the license server host name, hostid, and tcp 
port. This is defined only once in a license file. 
The daemon identifier defines the controlling 
license daemon and its full path. A license file 
may have multiple numbers of daemon identi- 
fiers. The feature identifier has controlling 
daemon, version, license expiration date, 
number of licenses, and a license string. Each 
license daemon controls multiple application 
features. 

License package 

Flexlm either comes by default with the appli- 
cation software or one can install it from the 
SUN Workshop CD-ROM. The actual package 
name on the SUN CD-ROM is SUNWlicsw. 
One can also install SUNWlit, a license instal- 
lation tool. 

License installation 

Installation and configuration of licenses can 
be implemented in multiple ways. This basical- 
ly depends on how many licenses you're run- 
ning and how many machines are using the 
license server. In a very simple case where only 
one machine is the license server and there are 
few licenses, you can follow this procedure: 

1. Append all the licenses to one file. Make 
sure you have only one SERVER line and 
the path of all the daemons is correct. 

2. Choose one area that's visible to all users 
from all the machines. You may choose any 
NFS-mounted partition like /usr/ local. 
Create one directory called j usr j local I licenses. 



3. Install the Flexlm tools (SUNWlicsw) in 
/ usr / local / licenses. 

4. Copy the licenses file as / usr /local/ 
licenes / license_file. 

5. On the license server, start the licenses with 

/usr/local/Ucenses/bin/lmgrd.ste -c 
/usr/ local /licenses/ 1 i cense_f i le» 
/usr/local/licenses/license_log 2>&1 & 

6. Edit the / etc /rc2.d/S851mgrd (installed by 
SUNWlicsw package) file to start the licens- 
es at every boot time. 

7. Define LM_LICENSE_FILE variable to /usr/ 
local/ licenses /license_file for all the users. 

8. If you get an update for some licenses, 
just edit/ append them to the licenses file 
and ask the Flexlm to reread the license 
file with 

/usr/local/licenses/bin/lmreread -c 
/usr/local/licenses/license_file 

If your site has a large number of licenses, 
then the maintenance of one single license file 
itself can become a problem. You can then make 
multiple license files for each application ven- 
dor, but make sure that all of them are talking 
to different tcp ports. Now you can start all of 
these licenses one by one, or better yet, edit 
/etc/rc2.d/S851mgrd and define all the license 
files there. Again point the LM_LICENSE_FILE vari- 
able to all the license files. With some planning, 
using the license manager doesn't need to be a 
difficult experience, 



Backup made easy 

by Vinay Gupta 



Backup is a real problem if you're man- 
aging a small site with no dedicated 
system administrator. By default, the 
Solaris server set has a great backup tool called 
the Data Backup utility. Second, it will allow 
only one machine backup on the local tape de- 
vice. If you want to back up two or more ma- 
chines on one tape device, then you need to 
buy additional licenses. 



A simple bourne shell 

Here's a simple bourne shell script that can 
be used to make a backup of one or more ma- 
chines. It's easy to understand, easy to change, 
and easy to customize per site requirements. 
This script basically uses two utilities provided 
by Solaris. These are uf sdump and mt, found in 
the /usr/sbin and /usr /bin directories, re- 
spectively, uf sdump backs up either all files or 



only changed files (since the last full backup) 
in a file system to a tape device, mt manipu- 
lates the tape drives. 

This script will take two arguments; the first 
is dump level and the second is host name. 
Normally we hate to make deeper than a level 
1 backup, but you can always customize the 
scripts according to your site policy. 

Note: In case of a disaster, you need to restore only 
two backup tapes, level zero and level one— but 
remember that any backup is always better than 
no backup. 

Here are some assumptions: hostO is the 
host name of the machine where you have 
physically connected the tape; the tape device 
is /dev/rmt/Oun; and hostl, host2, and host3 
are client machines. This also assumes that 
you're taking level zero on an increment level 
one on every other weekday. 

This script will generate some log messages 
that will go to the /var/ backup /log directory, 
and it will read the tape ID from the /var/ 
backup/tape_id file. This is the only file that 
you have to change manually every time you 
change the tape in the drive. This file has a 
tape number that matches the tape physically 
present in the drive. 

The number of tape changes will depend 
upon the capacity of your tape drive and the 
total size of your backup. For example, if you 
have four machines (host0...host4) each with 
6 GB of data area, and you have a tape drive 
capable of handling 24 GB (6X4) of data, and 
you want only one full backup in a week, then 
you need to change the tape and the tape_id 
file once a week. 

If your tape capacity isn't enough, then we 
suggest using level 0 for different machines on 
different days. After a week, you can think 
about appending the level 1 of some different 
machine to the same tape that has been used 
for level 0 of some other machine, provided 
your tape capacity allows that. For example, 
you can make a full backup of hostO on tapeOOl 
and append a level one backup of hostl to the 
same tape. Yes, you guessed it, human inter- 
vention is dependent on the ratio of total back- 
up data and tape capacity. 

Step-by-step explanation 

Here's a step-by-step explanation of the script 
shown in Listing A on page 10. The first line 
tells the script to use the bourne shell to exe- 



cute; then we have some comments about the 
scripts. Line 7 through 13 will check for the 
proper command line arguments. If they aren't 
supplied, then we report the usage and exit. 

We have defined some variables in lines 15 
to 22. Variable LEVEL and B_H0ST (host machine 
to be backed up) are derived from the command 
line arguments. Later on, we'll report an error 
if either host name isn't from the defined list 
or level is deeper than one. T_DEV is the tape 
device name — check your site for the correct 
device name. The TAPE_ID variable reads the 
tape ID from the user-defined file. 

Lines 24 to 43 check for the defined host 
name and define the raw device name to 
be backed up depending on the machine. 
If some machines have more then one raw 
device to be backed up, then you can add 
that area here as R_DEV1 and at the end of the 
script. This is where the actual ufsdump com- 
mand starts the job. 

Lines 45 through 63 make sure that you're 
taking either a level zero or a level one back- 
up; otherwise, it prints a message and exits. It 
also positions the tape to the end of written 
media if you're using the same tape for multi- 
ple workstations. This is required, because if 
you've removed the tape from the drive or if 
you've rebooted the workstation, then the tape 
will rewind itself. 

Here's an option if you want to erase every- 
thing before taking the backup. Just insert the 
following lines at this point: 

if test 'date +%a" = Tue 
then 

rsh $T_H0ST $MT -f $T_DEV erase 
fi 

This will effectively recycle the tape on every 
Tuesday. A better way to use this is to have it 
in a separate script and call from cron. 

Lines 64 through 66 will write about the 
tape ID and the actual file number on tape to 
log file, and the last line will do the trick while 
logging everything to log file. Finally edit the 
crontab file and add the entry for the backup, 
one example entry on hostl will look like: 

0 19 » » 1 /root/backup 0 hostl > / 
*Mev/null 2>&1 0 19 * * 2.3.4.5 / 
^root/backup 1 hostl > /dev/null 2>&1 

This will take the zero level backup of hostl 
on every Monday and level one backup on 
every other weekday. 



www.zdjournals.com/sun 



September 1999 9 



You can also add more features to this 
script. For instance, you can create archive 
files of each dump file as we did in "Make- 
Index: a tape utility." This will be a table of 
contents that can beusedbythe ufsrestore 
command. If you have an auto changer, then 
you can use the I option of uf sdump to load the 
next tape from the magazine. If you have an 
autoloader, then you can also use the mtx 
utility (freely available on the Internet, and 
it comes with HP autoloaders), mtx (only for 
autoloaders) can reduce the human interven- 
tion needed to perform your backups a lot, as 
it provides a way to load and unload the tape 
from the host machine itself. 



Restore 

You can use /usr/sbin/uf srestore to restore your 
data from the tape. You need to go to the right 
file on the tape if you're appending the multi- 
ple backups to one tape. The mt command can 
be used for jumping to a particular file on a 
tape. For example, if you want to go to the third 
file from the first file, then you should use: 

mt -f /dev/rmt/Oun f s f 3 

Do this before starting the restore option. You 
can also use the i option of ufsrestore for inter- 
active restore, where you can actually select 
the file or directories you want to restore, 



Listing A: Our level zero backup script 

1 #!/sbin/sh 

2 # Script to take level zero and one backup of UNIX file 
# systems. 

3 # syntax: backup [dump level] [host to be backed up] 

4 # 

5 # ver 1 .0 by Vinay Gupta 
6 

7 # Check for command line arguments. 

8 if test $# != 2 

9 then 

10 echo "Syntax: " 

11 echo "backup [dump level] [host to be backed up] " 

12 exit 

13 ii 
14 

15 # lets define some variables 

16 LEVEL=$1 

17 B_H0ST=$2 

18 T_HOST=hostO 

19 T_DEV=/dev/rmt/Oun 

20 DUMP=/usr/sbin/ufsdump 

21 MT=/usr/bin/mt 

22 TAPE_ID='cat /var/backup/tape_id~ 
23 

24 # Check if host to be backup up is one we have and 

25 # define area to be backed up on that machine. 

26 case $B_H0ST in 

27 host 1 ) 

28 R_DEV=/dev/rdsk/c0t2dOs0 

29 break 

30 ;; 

31 host2 ) 

32 R_DEV=/dev/rdsk/c0t2dOs6 

33 break 

34 ;; 

35 host3 ) 



36 R_DEV=/dev/rdsk/c0t2d0s3 

37 break 

38 ;; 

39 . ) 

40 echo "Please give one of hostl, host2 or host3 \n" 

41 exit 

42 ;; 

43 esac 
44 

45 case SLEVEL in 

46 0 ) 

47 rsh $T_H0ST /usr/bin/mt -f $T_DEV eom 

48 break 
49 

50 1 ) 

51 rsh $T_H0ST SMT -f *T_DEV eom 

52 FILE="rsh $T_H0ST $MT -f $T_DEV stati grep file ! 
*»cut -C12-15' 

53 break 

54 ;; 

55 * ) 

56 echo " Please take only level 0/1 dump only " 

57 echo " No fun in taken ng deeper level dumps " 

58 exit 

59 ;; 

60 esac 
61 

62 DATE='date +%m.%d.%Y v 
63 

64 # Generate some header for the log files. 

65 echo "This backup is going to $TAPE_ID 
^">/var/backup/log/$B_HOST.$DATE 

66 echo "This backup tape file is SFILE 
■»"»/var/backup/log/$B_HOST.$DATE 

67 SDUMP "$LEVEL"uf $T_HOST:$T_DEV $R_DEV » 
Wvar /backup/ log/$B_HOST.$DATE 2>&1 
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The ssh: what it ispaM 
and why you needpBa 




by Edgar Danielyan 

Back in the good old days of the Internet, 
one could assume that the information 
sent over the network wouldn't be cap- 
tured by sniffers and packet analyzers; we 
could just telnet or rsh to a host anywhere in 
the known Net and be 99 percent assured that 
no one was intercepting our passwords or data. 
Those days are long gone. If you're still using 
telnet or rlogin to access any host outside your 
LAN, read on — you've got a problem. 

The problem, as it is 

Standard Internet tools supplied with all UNIX 
systems, including the latest release of Solaris, 
use clear-text passwords for authentication 
over the network. These utilities include telnet, 
rlogin, rsh, ftp, and rep. This means that any 
data (including user names and passwords) 
sent and received using these tools are trans- 
mitted in clear text over the network and are 
vulnerable to interception and misuse. For a 
long time, people didn't pay much attention 
to this problem, but nowadays with the every- 
day expansion of the Internet and influx of 
new, not necessarily good users, this problem 
deserved attention and got a solution: the Se- 
cure Shell (ssh). 

The solution 

The ssh, developed by Tatu Ylonen of the Com- 
puter Science Department of the Helsinki Uni- 
versity of Technology Finland, solves all the 
aforementioned, and many other, problems. 
The two most important features of the ssh are 
its ability to provide an encrypted and authen- 
ticated, thus secure, channel of communication 
between two hosts over insecure networks, 
such as the Internet; and its unique flexibility 
and portability, allowing porting to almost any 
UNIX and many non-UNIX operating systems. 
In addition to providing a secure version of 
telnet, rsh, and rlogin all in one tool, the ssh 
has many additional features not found in the 
previously mentioned standard tools, such as 
protection against: 



• Interception of clear text user names and 
passwords 

• IP spoofing (when one host pretends to be 
another host) 

• DNS spoofing (when DNS entries are mod- 
ified to provide false DNS information) 

• Man-in-the-middle attack, when data trans- 
mitted over the network is modified on 
the fly 

• Various X Windows attacks (spoofing of Xll 
connections, etc.) 

How it works 

The ssh uses public key cryptography to en- 
crypt data and authenticate users across the 
network, almost seamlessly fitting into the 
standard UNIX environment. Using special 
protocol, also called the ssh, the client estab- 
lishes a connection over TCP with the host, 
which is encrypted using one of the support- 
ed encryption algorithms (for example, IDEA, 
Triple DES, DES, or Blowfish), IDEA being the 
default. The encryption keys are exchanged 
using RSA, thus providing a very high degree 
of security. Keys aren't saved anywhere and 
are transparently replaced every hour. 

Another great feature of the ssh is that it has 
built-in compression support, using the GZIP 
algorithm, which is really useful for sites with 
low bandwidth links. The actual compression 
ratio, of course, will depend on the nature of 
the data transmitted. 

Some applications of the ssh 

Besides being the plug-n-play replacement of 
telnet, rsh, rlogin, and rep, the ssh has a num- 
ber of not-so-widely used but, nevertheless 
very handy, features. For example, if you're 
using rsh for backups over the network, you 
can continue doing so — in most cases, transi- 
tion from rsh to the ssh will be painless. You 
can even use the ssh across a firewall by using 
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a feature called TCP Forwarding, or you can 
connect two subnets using PPP over the ssh, 
thus creating a Virtual Private Network 
(VPN). There are, however, some protocol im- 
plications with running PPP over TCP that 
aren't discussed here, such as a TCP in PPP 
over TCP re-transmission problem. See www. 
inka.de/~bigred/sw/ssh-ppp-new.txt for more 
information. 

Obtaining and installing the ssh 

There are both free and commercial versions 
of the ssh, available from the ssh Communica- 
tions Security (www.ssh.fi) and Data Fellows 
(www.datafellows.com) or directly from 
ftp://ftp.cs.hut.fi/pub/ssh/. 

However, before downloading or using the 
ssh, keep in mind that there are laws in some 
countries restricting or banning the use of 
cryptography. In the United States, it's illegal 
to import and then export the ssh. In other 
countries, the laws may be similar. 



Compiling the ssh is an easy task. Get the 
current version of the ssh, unpack it using 

gzip -c -d ssh. tar. gz ! tar xvf - 

Then change to the newly created directory and 

./configure 
make 

make install 

will do the job. The ssh is written in ANSI C, and 
requires an ANSI C compiler to compile (GCC is 
fine). The default configuration options for con- 
figure probably will suit most users; however, if 
you have a non-standard installation or would 
like to explore all the compilation-time configu- 
ration options the ssh has to offer, check out file 
INSTALL in the ssh sources. Some options you 
may want to change for your installation are 
shown in Table A. The ssh comes with a vari- 
ety of programs that are listed in Table B. 



Table A: The available ssh configuration options 



Option 


Description 


— prefix 


Where to install the SSH files (default is 
/usr/ local) 


— without-des 


Don't use single DES (you don't want to 
use it anyway, off by default) 


— with-securid 


Include support for Security Dynamics' 
SecurlD card 


— with-tis 


Include support for TIS 


— with-kerberos5 


Include and enable support for Kerberos 5 


— disable-server-xll-forwarding 


Disable Xll connections forwarding in the 
ssh server 


— disable-suid-ssh 


Install the ssh server without the SUID bit 



Table B: The ssh package contents 



Program 


Description 




The ssh server 


ssh 


The ssh client 


scp 


Secure rep 


ssh-keygen 


Utility to create RSA keys (both host 
keys and user keys) 


ssh-agent 


The ssh authentication agent 


ssh-add 


Utility to register new keys with the 
ssh-agent 


make-ssh-known-hosts 


Utility to create /etc/ ssh_known_hosts 
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A compilation note to Solaris x86 users: So- 
laris x86 uses syntax for assembler that's not 
supported by gmp provided by the ssh. The 
configuration will automatically detect this and 
disable assembler code. After you've compiled 
and installed the ssh, you need to configure 
sshd, the sshserver, to fit your requirements. 

Supported encryption algorithms 

The ssh supports a number of encryption al- 
gorithms, namely Blowfish, IDEA, DES, Triple 
DES, and Arcfour. Here are their general char- 
acteristics: 

• Invented by Bruce Schneier, Blowfish is a 
fast block cipher with 32- to 448-bit keys 
(the ssh uses 128-bit keys with Blowfish). 

• Arcfour is a fast stream cipher with variable 
key lengths (the ssh uses it with 128-bit 
keys), compatible with the RC4 cipher 
developed by RSA Data Security, Inc. There 
are some problems with this cipher, so we 
recommend using IDEA or Triple DES. 

• IDEA is a 128-bit block cipher, which is 
patented in many countries. It's faster than 
Triple DES but slower than Blowfish or 
Arcfour. This is the default cipher used by 
the ssh. 

• DES is an old, 56-bit block cipher. It's three 
times faster than Triple DES but much slow- 
er than Blowfish or Arcfour. The key length 
is fixed and isn't serious. Don't use this 
cipher. 

• Triple DES, a modification of DES, uses 
three keys in CBC mode. This cipher is 
required by the ssh, so you can't disable it. 

For more information on these encryption al- 
gorithms and ciphers, consult Bruce Schneier's 
Applied Cryptography (John Wiley & Sons). 

There are also two Usenet newsgroups on 
cryptography: sci.crypt and talk.politics.crypto. 
An FAQ for sci.crypt is at www.cis.ohio-state. 
edu/hypertext/faq/usenet/cryptography-faq/ 
top.html. For really interested folks, there's an 
IEEE Symposium on Research in Security and 
Privacy at www.ieee.org, and the Interna- 
tional Association for Cryptologic Research at 
www.swcp.com/~iacr. ACM also has a Special 
Interest Group on cryptography and security 



at www.acm.org, as does the IEEE Computer 
Society at www.computer.org. 

Configuring the ssh 

The default configuration, installed with make 
install in /etc/ sshd_config, is a generic one and 
will make the ssh server run. However, should 
you wish to check or customize the configura- 
tion, take a look at man sshd, which has all the 
options and detailed explanations. Here are 
some options you might want to specify: 

• IdleTimeout sets idle timeout limit for the 
ssh connections 

• IgnoreRhosts specifies whether the ssh 
honors. rhosts 

• IgnoreRootRhosts specifies whether the ssh 
has to use .rhosts for root logins 

• PermitEmptyPasswords specifies whether 
users with empty passwords can log on 

• StrictModes specifies whether the ssh has 
to check the file modes of the user's home 
directory and .rhosts file 

We recommend that you disable telnet and 
rlogin/ rsh/rcp in /etc/inetd.conf altogether 
and switch to the ssh. In this case, don't forget 
to start sshd on start-up in /etc/rc2.d. An op- 
tional argument to the sshd is "-b bits", speci- 
fying the RSA key size (default is 768, which is 
okay for most installations, with 512 bits being 
weak and 1024 bits very strong). Of course, a 
larger key size increases security but decreases 
performance, so it's probably best to leave it at 
768. It's possible to start sshd from the inetd, 
but there's no real advantage in doing so — for 
each incoming ssh connection, sshd would 
need to generate an RSA key, which may take 
some time on slower machines. And don't for- 
get to open port TCP/ 22 for the ssh on your 
firewall. 

Conclusion 

Any system is only as strong as its weakest 
link. Use of the ssh shouldn't preclude you 
from frequently changing passwords, using 
good, hard-to-guess passwords, taking care 
of physical security of your systems and net- 
works, and, of course, keeping informed of 
new developments. ^& 
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Why does traceroute work on my 
Windows box, but fail on my Sun box? 



Win 



by Lance Spitzner 

Traceroute is a popular utility used to 
troubleshoot networks. Implemented by 
Van Jacobson, traceroute identifies the hops 
that a packet takes from source to destination. 
This path lets us map the routers and systems 
that our packet goes through. Originally writ- 
ten for UNIX, Microsoft added its own version 
of traceroute (called tracert) to its Windows 
and NT operating systems. What many people 
don't realize is that while these tools look sim- 
ilar, they operate differently. 

These differences are critical in today's 
world of firewalls and ACLs (Access Control 
Lists) on routers. Often you'll find that one 
version will work, while the other fails. This 
is a result of how they work. 

UNIX versions of traceroute (www.metalab. 
unc.edu/pub/solaris) use UDP datagrams out- 
bound, and ICMP inbound. Traceroute begins 
by sending three UDP datagrams (port > 30,000) 
to the destination with a TTL (Time to Live) of 
1. The first hop decrements the TTL by 1. Since 
the TTL is 0, the first hop sends us an ICMP 
time exceeded in transit error (type 11, code 0). 
Traceroute receives this error, records the IP, 
and then sends three more UDP datagrams, 
with a TTL of 2. These packets will fail at the 
second hop. This mapping process of sending 
datagrams while incrementing the TTL con- 
tinues until the destination host is reached. 
Hopefully, the remote system isn't listening 
on the UDP port we've attempted to reach. If 
there's no daemon listening, the remote sys- 
tem sends back an ICMP port unreachable 
(type 3, code3). Traceroute then knows we've 
reached our target. 



Windows tracert uses the same concept, 
but ICMP requests (type 8, code 0) instead of 
UDP datagrams. Tracert begins by sending 3 
ICMP requests with a TTL of 1 to the destina- 
tion. The first hop decrements the TTL by 1. 
Since the TTL is zero, it sends back an ICMP 
time exceeded in transit error (type 11, code 
0). Tracert records this and sends three more 
ICMP packets to the destination, with a TTL 
of 2. These packets will fail at the second hop. 
This process continues until the destination is 
reached, which returns an ICMP reply (type 0, 
code 0). 

As you see, traceroute and tracert imple- 
ment the same concepts, but use a different 
method. It's this difference in methods that 
can cause your problems; one type of packet is 
allowed, while the other is denied. For exam- 
ple, let's say your routers allow all ICMP traf- 
fic, but deny all UDP traffic except for port 53, 
DNS. Tracert on Windows would work fine, as 
it uses only ICMP. However, traceroute on our 
Sun box would fail, as it uses UDP, which is 
denied by our routers. 

Another problem could be firewalls. Many 
firewalls can be configured to allow statefull 
connections to go through. If an ICMP packet 
passes through your firewall, your firewall 
may expect an ICMP return packet. However, 
if a UDP datagram passes through your fire- 
wall, your firewall may expect a UDP data- 
gram to return, when in fact it gets an ICMP 
packet, which it drops. By understanding the 
differences between traceroute on your Sun 
box and tracert on Windows, you can better 
understand why you're having problems. 



If you have any Solaris questions you would like answered, shoot your 
questions off to lance@spitzner.net, and Ping the Solaris Dude! 
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Easily convert man pages 
to text documents 




by Al Alexander 

Have you ever wanted to convert a man page intoXpla$fc40R docu^ 
ment? I do this occasionally when I want to share information via an 
email or other document format. jj% 

I used to think this was difficult, but then I discovered a simple way to do 
it. Here's the wrong way to write the man page for the I s command into a text 
file named ls.bad: 

man Is > ls.bad 

This keeps all of the formatting characters in your document, which is 
generally not what you want. Here's a better way that eliminates those for- 
matting characters: 

man Is ! col -b > man. txt 

The co I command with the -b option removes the undesirable backspace 
characters from the text stream, so the only thing left in your document is the 
text you want, in the format you want. 
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Inside Solaris reader survey 



With the explosive growth of the Internet and 
Solaris, we felt this would be a good time 
to get input from you, our readers. This 
will help us determine the topics that will best meet 
your needs. Your responses are extremely important — 
please take a few minutes to complete and return 
this form. 

You can choose from several ways to complete this 
survey. If you prefer to respond electronically, go to our 
FTP site at ftp.zdjournals.com/sun and download the 
file survey.txt. Then, fill in your answers, copy the doc- 
ument into the body of an email message, and send it 
to inside_solaris@zdjournals.com. 



To respond by fax or mail, first photocopy the survey 
form. Complete your answers, and then fax the form to 
(716) 214-2387 or mail it to us at: 

Inside Solaris 
ZD Journals 

500 Canal View Boulevard 
Rochester, NY 14623 

From the responses we receive, we'll select three at 
random. The readers whose forms are drawn will receive 
a free one-year renewal to Inside Solaris. To be eligible 
for the drawing, we must receive your form no later 
than October 30, 1999. Thanks for your help! 



1. What version of Solaris do you currently use? 

□ Solaris 7 □ Solaris 2.51 

□ Solaris 2.6 □ Other 

2. If you are not using Solaris 7, when do you plan 
to upgrade? 

□ Immediately □ Within a year 

□ Within 6 months □ Not sure 

3. How would you rate your level of experience 
with Solaris? 



Network topics 

Security 

Perl 

Tel 

Python 
Web Servers 
Firewalls 
Upgrade Issues 
Other 
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□ Novice 

□ Intermediate 



□ Experienced 

□ Expert 



How would you describe the technical level of the 
articles in Inside Solaris? 



□ Too simple 

□ About Right 



□ Too Technical 



What kind(s) of articles would you like to see more 
of (1 being little interest)? 

Code-intensive programming techniques 
Quick "how-to" tips 
Performance and tuning articles 
Case studies 
Java articles 



6. Do you use email and / or the Web? 

□ Every day □ Occasionally 

□ Never 

7. Do you make use of our Web /FTP sites? 

□ Download sample files 

□ Read back-issue articles 

□ Receive ZDtips 

8. Please share any suggestions or comments you 
have about Inside Solaris. 
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